A digital certificate may be created in a public key infrastructure (PKI) and may be used to identify ownership of a public key as a part of a cryptographic protocol executed to authenticate an end entity (i.e., a user or device) and subsequently grant access to a service. In order to obtain the digital certificate from a PKI, the end entity typically sends a certificate signing request to a component (for example, a registration authority (RA) or a certificate authority (CA)) in a PKI. The certificate generated by the PKI certifies the ownership of a public key by the named subject of the certificate and binds an identity of the end entity to the public key by including the identity of the end entity and the public key in the certificate and signing the certificate with the private key of a trusted CA. The CA may include other information about the end entity in the certificate. For instance, the CA may include attributes that can be used to provide an indication of the applications and services that the end entity should be allowed to access, or other attributes of the end entity such as a role or rank, or group affiliation. Once generated, the digital certificate allows others (relying parties) to rely upon signatures or assertions made by a private key that corresponds to the public key in the certificate. The process of obtaining a certificate is referred to herein as certificate enrollment. Certificate enrollment may be a long and cumbersome process, depending on the security requirements of an enterprise associated with a given type of certificate. For this reason, certificates are generally issued for long periods of time, such as months or years.
There are instances where a device is shared by two or more users. In these instances, there are challenges associated with certificate issuance and management. Consider an example where an enterprise implements a device sharing arrangement such that a group of devices may be shared by a group of users and each user is randomly assigned a device from a pool of devices for a specific period, for example, at the beginning of a shift. In such a sharing arrangement, it may be operationally restrictive to ensure that a given user always uses a given device. In this example, a first user may use a device for a first shift and a second user may use the same device for a second shift. When a device is used by multiple users, a single certificate issued to the device cannot be used to identify the current user.
It is also infeasible to provision the shared device with certificates for each potential user of the device. Consider that if the certificates issued to users sharing a device are long lived (for example, the certificates are issued for several months or over a year), the shared device would have to store certificates for, in some cases, hundreds of users. If the shared device with certificates for multiple users is lost or stolen, the certificate for each user that is stored in the device would have to be revoked. Furthermore, because each user is set up to share multiple devices, a user would have at least one certificate on each shared device. When a user with a certificate on multiple shared devices is terminated by the enterprise, the user certificate may have to be removed from each of the shared devices. As an alternative, if the certificates issued are short lived (for example, the certificates are issued for a single shift), the users may have to go through a potentially lengthy and costly enrollment process at the beginning of each shift. The cost of the daily enrollment for each user is unacceptably high.
In addition to the challenges associated with certificate issuance and management in device sharing arrangements, a device may not have a user interface for enabling a user to logon and activate a certificate assigned to the user, making it difficult for a user of the device to obtain a certificate on the device. To overcome the obstacles associated with certificate issuance and management, a user of a device (referred to herein as the primary device) needing access a given service is also issued a secondary device. An example of the secondary device may include a smart badge that is configured to wirelessly communicate with the primary device via a wireless interface, for example, Bluetooth, Bluetooth Low Energy, or near field communications (NFC). Another example of the secondary device may include a personal identity verification (PIV) card or a smart card that may be configured to wirelessly communicate with the primary device via a wired or wireless interface or via a contact or contactless interface. Wired interfaces for a secondary device may use the ISO 7816 standard for contact based smart card communications.
In order to access, for example, a service or network, via the primary device, the user may pair the secondary device to the primary device (for example, via Bluetooth wireless communication, NFC wireless communication, or by a contact based/wired connection). Subsequent to pairing the devices, in some implementations, the secondary device may answer a challenge presented to the primary device when the primary device tries to access the service or network. In some implementations, subsequent to pairing the devices, the primary device may obtain credentials (referred to herein as “derived credentials”) from a third party, wherein the secondary device is used to prove an identity of a user prior to the primary device obtaining the derived credentials. Subsequent to obtaining the “derived credentials”, the primary device does not need be paired with the secondary device each time the primary device accesses the service or network. Instead, the primary device may use the derived credentials to access the service or network.
There may be instances where the user may need to obtain a user certificate on the primary device to access a service when both the primary device and the secondary device have no access to fixed infrastructure services. For example, during an emergency situation when both the primary device and the secondary device have no access to PKI services in the fixed infrastructure, the user may need to obtain a certificate for accessing a local service (e.g., a service on a local ad hoc network with no connectivity to the fixed infrastructure) using a previously obtained certificate issued to the secondary device. However, there is no current avenue for the primary device to obtain a certificate for accessing the local service while both the primary and secondary devices are off-line and have no access to fixed infrastructure services.
Accordingly, there is a need for an apparatus and method for deriving a certificate for the primary device while both the primary and secondary devices are off-line.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.